AzLocal.UpdateManagement v0.8.76 - Step.6 sideload preflight

Patch release. Adds a Microsoft-hosted Windows preflight job (GitHub Actions) / preflight stage (Azure DevOps) in front of the opt-in Step.6 sideload-updates.yml pipeline. Before v0.8.76, triggering Step.6 without first completing the opt-in setup (master gate SIDELOAD_UPDATES not set, or set without a self-hosted azlocal-sideload runner) produced Status: Skipped with no logs, no annotation, and no actionable feedback - operators had to read the YAML to understand why. v0.8.76 prepends a preflight job (runs-on: windows-latest, ~10s, no Azure access) that ALWAYS runs and writes a clear panel to the run step summary explaining what is set, what is missing, and how to enable Step.6. Also broadens the master gate to accept 'true' / 'True' / 'TRUE' / '1' (was strict-literal 'true' only).

No public API change or new exports (still 60).

What changed

New (GitHub Actions sideload-updates.yml)

• New preflight job on runs-on: windows-latest with permissions: actions: read, contents: read. The job always runs (no if: gate).
• Outcomes:
  • Gate OFF -> succeeds with a ::notice annotation + full enablement walkthrough in the step summary.
  • Gate ON + SIDELOAD_STATE_ROOT missing -> fails (::error, exit 1) with a missing-variable panel.
  • Gate ON + runner enumeration finds no online azlocal-sideload runner -> fails with a no-online-runner panel.
  • Gate ON + runner API 403/404 (typical, GITHUB_TOKEN lacks admin) -> succeeds with a manual-verification warning.
  • All OK -> succeeds with a Preflight passed panel.
• The sideload job gains needs: preflight so it cannot queue indefinitely when prerequisites are missing.

New (Azure DevOps sideload-updates.yml)

• New Preflight stage on pool: vmImage: windows-latest. Validates the gate + SIDELOAD_STATE_ROOT; uploads the markdown panel via ##vso[task.uploadsummary].
• Does not enumerate ADO agents (the Agent Pools (read) scope is not normally granted to the pipeline identity).
• The Sideload stage gains dependsOn: Preflight.

Changed

• Master gate broadened: both sideload-updates.yml files accept SIDELOAD_UPDATES in 'true' / 'True' / 'TRUE' / '1'. GH uses contains(fromJSON('[\"true\",\"True\",\"TRUE\",\"1\"]'), vars.SIDELOAD_UPDATES); ADO uses an or(eq..., eq...) condition.

Docs

• Automation-Pipeline-Examples/docs/sideload.md - section 6 gate row updated to reflect the four accepted values, header note documents the preflight, new section 9 "Preflight (v0.8.76+)" with the full behaviour matrix and a rationale for why a Microsoft-hosted Windows runner is the right host for preflight.

Pin

• GENERATED_AGAINST_MODULE_VERSION bumped from '0.8.75' to '0.8.76' across all bundled pipeline templates.

Why windows-latest for preflight

The preflight does not touch the cluster fabric, Key Vault, or any Azure resource. It only reads workflow / pipeline variables, optionally queries the GH runners API with GITHUB_TOKEN, and writes markdown to the step summary. There is no domain-membership or VLAN-reachability requirement, so windows-latest is the correct minimal-cost host (~10s) and aligns with every other pipeline in the suite. The sideload job itself still requires the on-prem self-hosted runner with the azlocal-sideload label - that part has not changed.

Tests

• New Pester regression cases assert both sideload-updates.yml files contain the preflight job/stage on windows-latest, the needs: preflight / dependsOn: Preflight gate, the runner-enumeration permissions (GH), the ##vso[task.uploadsummary] panel (ADO), and the broadened gate values.
• Full suite: 1145 passed, 0 failed (Pester v5.7.1, PowerShell 5.1).

See CHANGELOG.md and README.md "What's New in v0.8.76" for the full entry.